1. Field of Invention
This invention relates primarily to accounts such as credit card accounts, checking and/or savings accounts, and any related method of electronic funds. Also note that this invention can take many forms and it is the purpose of this draft to explain the most common embodiments of this invention. This invention includes a compact, portable calculating apparatus having a memory for storing a price and an internal clock for conveniently determining the time and/or date value for computing an authorization code and its use for calculating and allowing a vendor to store protected, anti-fraud bank security deposits for annual fees and other purposes, even after the later changing of a formula by the account holder.
It is well known in the prior art that traditional credit cards and other accounts can be overcharged and fraudulently used. The main purpose of this invention is to prevent credit card fraud and to simultaneously allow a vendor to make an annual fee or other charge to a credit-card user""s account, even after constant changing of one""s own formula, which comprises variables of date, time, and price.
2. Description of Prior Art
U.S. Pat. No. 5,485,510 to Raymond O. Colbert (Jan. 16, 1996) mentions a way of providing a method to produce an authorization code that keeps the account number of a card confidential. This method normally requires the account holder to call in to receive an authorization code from a bank and send the code to a merchant for a purchase. The account holder makes a purchase by providing an authorization code and not the account number to a vendor, ensuring its security. This prior art patent discloses a way to include a time limit for a vendor to make a charge, but does not mention any method of providing to an account holder a calculating apparatus that can conveniently store on file a preset formula which can be used to make purchases possible, nor does the prior art patent disclose any portable apparatus having an internal clock for creating the necessary time and/or date restrictions. This method also only explains a method of making phone transactions safer against fraud, but does not protect against fraudulent charges made by someone who documents your account number and makes charges by other methods.
In U.S. Pat. Nos. 6,023,682 and 6,052,675 to R. Checchio (They disclose the same invention.), a method is explained for using an apparatus to determine whether or not a credit card user is an authorized user during a transaction. In use, an authorized user makes a purchase by first entering a price into a purchase apparatus, which is then encrypted into a code using a pre-stored PIC as a xe2x80x9ckeyxe2x80x9d. The method explains that the credit card number, and the xe2x80x9cpurchase tokenxe2x80x9d are then transferred to a merchant, who then transfers the data to a verification system to determine whether or not a user is an authorized user. Only an authorized user and the bank have knowledge of the confidential PIC, which a verification system uses to compare a xe2x80x9ctest tokenxe2x80x9d with a xe2x80x9cpurchase tokenxe2x80x9d; and that a third party who gets access to a lone credit card cannot use it without the confidential PIC. This only allows the merchant to determine whether or not a user is authorized, and the main flaw is that a dishonest merchant, whom allows an authorized user to use one""s card at a vendor location, can use a valid xe2x80x9ctest tokenxe2x80x9d repeatedly for a multiple charge amount.
Since the purpose behind U.S Pat. No. 6,052,675 was simply to determine whether a card-user is the real user when making a purchase (without comparing signatures), its inventor failed to recognize that also including time-date data as well as price encryption information would stop a merchant from fraudulently using a credit card at all. The patent just explains that a calculating apparatus to produce a xe2x80x9cpurchase tokenxe2x80x9d may contain various types of information for validating that a user is authorized to make a transaction. In addition, U.S. Pat. No. 6,052,675 to R. Checchio, does not even mention the idea of a calculating apparatus having an internal clock for encrypting time AND date data into a xe2x80x9cpurchase tokenxe2x80x9d nor does it explain whether or not a merchant having prerecorded data can use the exact same price and credit card data again (on the SAME DAY) for a duplicate charge. The method disclosed in U.S. Pat. No. 6,052,675 to R. Checchio simply cites that a string of data xe2x80x9cCAN also include other types of information, for example, vendor name, type of lease, type of purchase, date of sale, category of merchandise, location of the vendor or any other relevant piece of information . . . that would serve to distinguish a particular purchase or lease transaction.xe2x80x9d
If a bank allows a xe2x80x9cpurchase tokenxe2x80x9d or authorization code having valid purchase amount data to be used more than once on the same day, a merchant can use the same information over and over for multiple charges of the same purchase amount. This would breach security to a cardholder. Since it is such a critical function of a calculating apparatus to have its own internal clock to produce time data (and not JUST date data) restrictions to correctly perform, but no calculating apparatus with an internal clock to produce a time figure is mentioned in U.S. Pat. No. 6,023,682 to R. Checchio OR in U.S. Pat. No. 5,485,510 to Raymond Colbert (even though the first cites the latter!), an internal clock within a calculating apparatus to produce time-date variables, therefore, cannot be considered obvious. It is, once again, very important to provide a method so that a person who has a card number cannot increase the price of a charge, make a charge again with the same price on a different date and/or time, or make a valid charge again with the same date-time-price data once a valid charge is withdrawn.
Also, other flaws of U.S. Pat. Nos. 6,023,682 and 5,485,510 can be recognized after being thoroughly explained. It is well known that some companies, such as car rentals, require a credit card number to be held as a payment option so that any losses to the company can later be compensated by charging a predetermined amount on the credit card. This is known as a security payment option. The main problem with U.S. Pat. No. 5,485,510 to Raymond O. Colbert, is that without an advanced system of storing and verifying Price-Date-Time data by a bank, security deposits, annual fees, and later payments would have difficulty being collected at a later date when a formula is changed by the cardholder. An account holder may find it necessary to communicate price, date and other data to a merchant for being held as a security deposit, then change a formula for producing an authorization code if its user thinks that a particular merchant, after being visited by the particular customer for a long time, has determined a pattern to produce an authorization code.
Also, if a dishonest person somehow acquires a cardholder""s formula, the account holder should be able to change his formula without blocking any annual fees or other services that are put on a particular credit card. There would be a great inconvenience in having to call the account holder, get his authorization code and all variables associated with a purchase that utilizes a newly created formula, then run the account to collect payment from the credit card user. This can be extremely problematic if an account holder decides to damage merchandise such as a car and be called to get his authorization code. In most instances, the account holder after having damaged merchandise may not want to give the required information for the merchant to collect payment. This would in turn defeat the purpose as to why the company held the account number on record and would negate the reason to holding a credit card number.
Also, U.S. Pat. No. 6,052,675, does not disclose any method to avoid this problem if a formula or xe2x80x9ckeyxe2x80x9d is changed. Another method for the company to do in this instance would be to charge the card in advance and hold the deposit in a savings account. This can be troublesome for two reasons. One, the drop in credit may seriously render the ability of the account holder for other necessary purchases. Second, the resulting bank fees and interest from withdrawing funds may affect the account holder even if the funds are later returned. After very careful examination, one realizes that there needs to be a systematic method of security measures to prevent fraud by providing price, date, and other variables to produce authorization codes, yet still allow an account holder to change one""s own formula, and still allow companies to collect security deposits if needed without interest charge complications. Again, after careful examination, the reader realizes that not every system for providing authorization codes is flawless, convenient, or perfectly secure. Thus, the industry needs a method of producing a safe credit card transaction without the above limitations.
The prior art references contain disadvantages and furthermore fail to disclose:
(a) a systematic method of producing an authorization code so that electronic security deposits may be held by a company, even after the later changing of a formula by an account holder, without accruing interest or other fees to the account holder;
(b) a method of security to prevent hackers from running prerecorded account numbers with guessed variables and authorization codes;
(c) a method of calculating an authorization code by providing a portable, formula-storing calculating apparatus having an internal clock for conveniently calculating the date, time, and price to produce an authorization code so that a merchant cannot use the exact same credit card number and price data (on the same day) for a double charge;
(d) III. Description of Terms: The reader may refer to the following lettered terms for meaning as these terms are used throughout the disclosure. These given terms are by no means to limit the scope of the invention, as they are not claims, but are only provided to help the reader understand, make, and use the preferred embodiment of the present invention.
(a) C=C-device: preferably a small calculating device with a securely stored, changeable algorithm or formula for calculating authorization codes, preferably taking the form of a durable, metallic credit card with a computer chip embedded within, said calculating device preferably having a small liquid crystal display (LCD) screen to display an authorization code and the date and time used to create such a code, said calculating device preferably having numeric keys similar to that of a calculator to allow the entering of the changeable, stored formula and the entering of a price P for purchases, said calculating device preferably containing a magnetic stripe and/or an electronic signal device preferably being read-only-memory means with said stored formula being stored along a parallel circuit at the time of a data transmission, whereby allowing the transfer of data to a merchant""s reading device without said formula being readable or changeable by said reading device during the transfer of data during a purchase transaction.
(b) R=R-device: the payee or merchant reading device used to run or process the information being sent from a C-device, said reading device preferably containing a card slot wide enough to allow said C-device to be swiped through and read by said reading device, said reading device also preferably containing an electronic sensor capable of receiving an electronic signal from said C-device, said reading device also preferably containing a symbolic keypad so that values such as the price, authorization code, and serial number of any C-device can also be manually entered for distant purchases, said reading device also preferably containing modem means whereby allowing said reading device to communicate with a distant verification device of a bank or financial institution and collect electronic payment.
(c) V=V-device: the verification device of a bank or financial institution that has an exact copy on file of a C-device""s customizable, preset formula for calculating an authorization code, said verification device also preferably storing the life range of any formula and preferably all past purchases along with date and time data of said past purchases, said verification device allowing a merchant""s R-device to receive payment only with a correct authorization code and other correct account information and declining a merchant""s R-device if there is an invalid authorization code or other invalid account information, whereby allowing an account holder the added security against fraudulent deductions.
(d) F=Formula: a C-device""s own unique algebraic equation utilizing the variables of D, T, P, and a predetermined set of numbers in a predetermined fashion, said predetermined set of numbers and said variables being used in conjunction to produce an authorization code, said algebraic equation preferably being customizable by said C-device""s own account holder, whereby allowing more security and flexibility to said account holder.
(e) PIN Code: a personal identification number or password an account holder must enter into a C-device in order to be able to operate or utilize said C-device""s ability to calculate an authorization code, said password preferably being customizable or changeable by said account holder to allow own individual security, said password being necessary to be entered once every predetermined time period as determined preferably by said account holder, whereby allowing more convenience for said account holder to shop without reentering said password into said C-device until said predetermined time period.
(f) M=Merchant number: the license number issued by a bank or financial institution for the identification of an existing entity licensed to do business with said bank, said license number being used to identify the payee or receiving end of an existing account number.
(g) L=Location number: the web site address or tracking number used to identify the exact location of an R-device at the time of a transaction so that the merchant""s position is known by the bank""s verifying device, said web site address being one preferably at a preset location which is issued by the bank to allow or authorize said R-device to run account numbers and deduct funds.
(h) S=Serial number: the account number used to label any particular C-device, said account number being used to establish the identity of an existing entity""s funds availability, said account number preferably being unique enough to establish individual identity over many other potential account numbers, said account number being integrated with the name of said existing entity.
(i) P=Price: the exact U.S. dollar value of a charge during the day and the time said charge was run, with dollars (d---d) first, and cents (c---c) next, said dollars (d---d) and cents (c---c) being separated with a decimal point, however, said dollar charge sometimes being estimated by dropping all fractions of a cent after the hundredths place.
P=($Price)=d---dc---c
(j) D=Date: using Standard Military Time, the day of a charge represented by the combination of numbers being run together, always beginning with a decimal point (.), followed by the 2-digit month (mm), followed by the 2-digit day (dd), and ending with all the digits of the year (y---y).
D=(Day)=.mmddy---y
(k) T=Time: using Standard Military Time, the time of a charge represented by the combination of numbers being run together, always beginning with a decimal point (.), followed by the 2-digit hour (hh), followed by the 2-digit minute (mm), and ending with all the digits of the second (s---s), however, said time sometimes being estimated by dropping all fractions of a second after the hundredths place.
T=(Time)=.hhmms---s
(I) A=Authorization Code: the resulting, computed number after a C-device has substituted the values of D, T, and P through said C-device""s predetermined formula.
(m) K=Combination Number: the string of variables M, L, S, P, D, T, and A being run together in a predetermined sequence.
(n) R=Formula Life Range: the time span or range of the existence of a formula being represented by the exact date/time point of establishment of said formula, being followed by a hyphen (-), and ending with the exact date/time point of the alteration or deletion of said formula.
R=date/time point of establishmentxe2x88x92date/time point of alteration or deletion
(a) Feb. 23, 2001 14:21:21-Feb. 23,.2002 15:21:35 (Expired)
(b) Jan. 21, 1982 02:02:21-Jan. 22, 1999 14:28:56 (To Date)
(c) Dec. 19, 2045 08:09:25-Mar. 20, 2046 02:24:23 (Expired)
Important note: The formula life range is recorded at the establishment of the very first formula. The deletion point of an in-force formula would be verified as xe2x80x9cto datexe2x80x9d and the recording V-device would have a clock displaying the current date and time that variables of D-T would be allowed for use. Variables of D-T received by a V-device having a combined value later than what is displayed along the V-device""s clock cannot be validated. For this reason, it is preferable to have a C-device""s clock set slightly behind that of a V-device.
When a formula is deleted or changed, it is considered expired. A formula and its life range need only be stored when a charge-credit is recorded by a V-device during the life of said formula, since only charge-credit deposits can later be turned into available funds even after the life of said formula. A previous formula can then be deleted after all charge-credits during the formula life range of said previous formula have been used.
(o) Electronic Security Deposit: an electronic deposit being made by an account holder by giving a merchant S-P-D-T-A data to be run along a network and allowing the price P to be credited back to said account holder""s serial number S so that the later changing of a formula F will not hinder later withdrawal of said price P by said vendor.
(p) Date/Time Combination or D-T Combination: a timepoint being stored in memory by a V-device which is the exact moment of a charge to an account.
Besides the disadvantages of the prior art methods, several advantages of the present invention are:
(a) to provide a method where a PIN code must be entered into a C-device, but only as needed every predetermined time period, as established by the authorized user, so that a lost or stolen C-device cannot be used without reentry of said PIN code, as determined by the card holder""s pre-established time period;
(b) to provide a method so that a formula F for calculating an authorization code can be conveniently-changed by the account-holder if said formula is discovered by someone other than the bank or account holder, but does not interfere with a third party from obtaining a preset limit of annual fees, nor compromises the security of the card holder;
(c) to provide a convenient method and system for calculating the value of an authorization code by providing a compact, versatile self-calculating apparatus with an internal clock, preset stored formula and variables of D for date, T for time, and P for price, so that calling to get an authorization code from a bank is unnecessary and fraudulent, double charges cannot be made on an account;
(d) to provide a convenient method for making purchases by requiring that an authorization code be necessary to validate any and all charges;
(e) to provide a method of making purchases by providing a C-device containing a transmitter with read-only-memory means and a pre stored formula being stored along a parallel circuit at the time of a data transmission, whereby said C-device is capable of transmitting an authorization code and given variables to an R-device without said C-device""s preset formula F being readable or changeable by said R-device during the transmission;
(f) to provide a method that allows a merchant to be located when running an account number and only having an X number of times to run an invalid authorization code before not being able to run said account number at said location for a predetermined time period, whereby stopping hackers from guessing numbers and allowing possible investigation of said merchant;
(g) to provide a method of conveniently producing a formula for each individual account by allowing each account holder the luxury and flexibility of calling in to create one""s own formula, whereby providing increased security to said account holder if the formula of a C-device is discovered.
(h) to provide specifications of a compact, versatile, and inexpensive calculating apparatus capable of being affordably mass produced by banks or financial institutions without the need for customization of every calculating apparatus, such as the stamping of each individual account holder""s name, account number, or other data onto said calculating apparatus, but by instead allowing an authorized user the ability and flexibility of entering in one""s own account information, storing one""s own self-created formula, and storing one""s own self-made PIN code and its reentry preferences into a generic, usable-by-anyone calculating apparatus.
Figures and Reference Letters:
A=Number representing the Shift Value of a Function Key. Example: pressing 7/P when a 1 is displayed here would yield a 7; pressing the same key when 2 or 3 is displayed yields the second or third function, being the P.
B=positive or negative value of a number
C=LCD Screen
D=Location of the Built-in Electronic Radio Transmitter (Read-Only-Memory Design)
E=Card Swipe (Read-Only-Memory Design)
F=Function Key
H=MEM A=Memory A for storing Serial, PIN, and formula data in a C-device
I=Circuit for transmitting data from MEM A to MEM B
J=Switch for opening/closing of the circuit in I
K=MEM B=Memory B for temporarily storing received data from MEM A
Other Functions:
a) P, D, T, A Keys for entering variables into a formula
b) xcfx80, ÷, +,=, and other functions for building an equation utilizing P, D, T and A
c) In=letters-numbers for changing between numbers and the alphabet display
d) cl=clock function for entering the time/date in a C-device""s clock
e) LC=Last Charge for using the exact same P, D, T, A data of a previous charge
f) ENT=for Entering the value of a PIN, price, formula, or other values
g) Sftxe2x86x92=Increase the Shift Value by 1
h) Sftxe2x86x92=Decrease the Shift Value by 1